Blockchain-based state verifications of software component vulnerability database for software products

ABSTRACT

A technique includes determining, by a computer, entries of a software vulnerability database that is associated with a plurality of components associated with a release of a software product. The technique includes determining, by the computer, a block of a blockchain representing a vulnerability state of the plurality of components; and associating, by the computer, the block of the blockchain with the product release.

BACKGROUND

When a software product is released, the code of the product may bescanned in an enumeration process to determine an inventory of itemsthat are contained in the product, including third party components. Asan extension to the enumeration process, a software componentvulnerability and exposures database, such as the Common Vulnerabilitiesand Exposures (CVE) database maintained by the MITRE Corporation, may bescanned for potential vulnerabilities that have been linked to thethird-party components of the product.

The CVE database contains entries for publicly known vulnerabilities. Anentry of the CVE database may contain such information as identification(ID) number, a description (e.g., a description that identifies the nameand vendor of the affected product, the versions of the product that areaffect, the vulnerability type, the impact, how access is made toproduct to exploit vulnerability, program code and inputs involved, andso forth), and a reference to a publicly available source forinformation on the vulnerability. When the search of the databasereveals that a particular third-party component has a vulnerabilityrisk, then the third-party component may be inspected and mitigated, asappropriate, to address the vulnerability. When there are no un-triagedor un-mitigated vulnerability risks for the product, then the product isallowed to be released.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of a computer system having a securityanalysis and marking engine and a security reporting engine according toan example implementation.

FIG. 2 is an illustration of a master database blockchain according toan example implementation.

FIG. 3 is an illustration of a security component vulnerability entry(SCVE) blockchain according to an example implementation.

FIG. 4 is an illustration of information added to a block of the masterdatabase blockchain by a central authority according to an exampleimplementation.

FIG. 5 is a flow diagram depicting a technique to generate a validationstamp for a software product according to an example implementation.

FIG. 6 is a flow diagram depicting a technique to extend an SCVEblockchain according to an example implementation.

FIG. 7 is a flow diagram depicting a technique to associate a block of ablockchain representing a vulnerability state of components associatedwith a release of a software product according to an exampleimplementation.

FIG. 8 is an illustration of machine executable instructions stored on amachine readable storage medium to cause a machine to associate a blockof a blockchain with a release of a software product according to anexample implementation.

FIG. 9 is an illustration of an apparatus to generate a stamp to beassociated with a release of a software product, where the stamprepresents an index to a block of a blockchain representing a state of adatabase that identifies vulnerabilities according to an exampleimplementation.

DETAILED DESCRIPTION

A provider of a software product release may publish a list ofthird-party components that are contained in the release. Consumers ofthe software product may assume that the software provider checked allpotential vulnerability risks of the third-party components against asoftware component vulnerability and exposures database (also called a“software component vulnerability database” herein), such as the CVEdatabase; and the consumers may assume that the provider addressed andmitigated the risks as appropriate. Consequently, the consumers mayeffectively ignore vulnerability risks of the third-party components.This may not be the best practice, however, as after the productrelease, entries for the third-party components may be added to thesoftware component vulnerability database to account for newlydiscovered vulnerability risks, and entries may be supplemented with newinformation about entries for the third-party components. Moreover, someentries in the software component vulnerability database may be mereplaceholders to reserve IDs for future database entries. Accordingly, aplaceholder entry may have been created in the software componentvulnerability database at the time of the product release; and after theproduct release, the entry may be updated with a description thatidentifies one of the third-party components as having a vulnerabilityrisk. Even though the reserve entry existed at the time of the productrelease, the provider did not address the vulnerability risk.

As can be appreciated, due to the everchanging nature of the softwarecomponent vulnerability database, it becomes challenging for theprovider of the software product to know and prove which particularvulnerabilities were described in the database at the time of the scanof the database. In other words, it may be challenging for the providerto and prove the state of the software component vulnerability databaseat the time of the software product release.

In accordance with example implementations that are described herein, aprovider of a software product may publish a verification stamp for thesoftware product. More specifically, in accordance with exampleimplementations, a particular release, or version, of a software productmay be associated with a published verification stamp that containsreferences to the following blockchains: a reference to a block number,or page, of a blockchain that is associated with a component inventoryof the software product; and a reference to a block number, or page, ofa blockchain that is associated with state of a software componentvulnerability database. With this information, the provider of thesoftware product can prove which particular vulnerabilities weredescribed in the software component vulnerability database at the timeof the provider's scan of the database; and consumers of the softwareproduct, with this information, are made aware of the vulnerabilityrisks that were and were not addressed by the software product provider.

In the context of this application, a “blockchain” refers to acryptographic ledger of transactions. In general, as its names implies,a blockchain refers to a linked set of blocks. Each block represents oneor multiple transactions, and each block, except for the initial genesisblock, is linked to a prior block of the blockchain. More specifically,the blocks are arranged in a sequence (beginning with the genesisblock), and with the exception of the genesis block, each block containsa cryptographic hash of the prior block. The cryptographic linking ofthe blocks preserves the integrity of the recorded transactions, as evena small change to one of the blocks in a tampering effort changes thehash value of the block and exposes the tampering effort.

For the application blockchain, each block may be associated with adifferent version, or release, of the software product. The transactionsof the block represent changes to the composition of the product (e.g.,new components, removed components, and modified components).

The blockchain that is associated with the state of the softwarecomponent vulnerability database is referred to as the “master databaseblockchain” herein. In accordance with example implementations, a blockof the master database blockchain is associated with a set of one ormultiple transactions that change the software component database. Asexamples, a given block of the master database blockchain may containone or multiple of the following transactions: a transaction to add anentry to the software component vulnerability database; a transaction todelete, or remove, an entry from the software component vulnerabilitydatabase; a transaction to modify an entry to the software componentvulnerability database; or a transaction to reserve an entry in thesoftware component vulnerability database (i.e., an entry ID was createdas a placeholder for a future complete entry containing a description, areference to a publicly available source, and so forth). In accordancewith example implementations, a given block of the master databaseblockchain may represent a transaction to publish a copy of the softwarevulnerability database.

In accordance with example implementations, each block of the masterdatabase blockchain contains multiple blockchains, which correspond tothe entries of the software component vulnerability database. Morespecifically, in accordance with example implementations, each block ofthe master database blockchain contains a blockchain (called an “SCVEblockchain” herein) for each entry of the software componentvulnerability database. For a given SCVE blockchain, each block of theSCVE blockchain represents one or multiple transactions for thecorresponding entry of the software component vulnerability database.Therefore, for given block of the master database blockchain, the lastblock of each SCVE blockchain represents the current state of acorresponding entry of the software component vulnerability database.

The software component vulnerability database may be modified (i.e., toadd, delete, modify or reserve entries) by authorized parties called“security reporters.” For example, the security reporters may beaffiliated with different software providers. In accordance with exampleimplementations, a database authority (a single central authority, suchas the MITRE Corporation, for example) may be responsible for issuingcredentials to the security reporters. In accordance with exampleimplementations, when a change is to be made to an entry of the softwarecomponent vulnerability database by a security reporter, the securityreporter accesses the most recent block of the master databaseblockchain and more specifically, accesses the most recent block of theSCVE blockchain (of the most recent master database blockchain) thatcorresponds to the entry and generates the next block of the SCVEblockchain representing the change.

If the entry is a new or reserved entry that is being created, then thensecurity reporter generates the initial, or genesis, block for a newSCVE blockchain for the entry. If the security reporter is changing anexisting entry, then the block of the SCVE blockchain describes thechain. The SCVE blockchain is digitally signed by the security reporterand communicated to the database authority. After the database authorityvalidates the new SCVE blockchain, the database authority incorporatesthe new SCVE blockchain into a new block for the master databaseblockchain (which may also include one or multiple other SCVEblockchains), digitally signs the new block and publishes the new blockfor the master database blockchain.

As a more specific example, FIG. 1 depicts a computer system 100 inaccordance with example implementations. In general, the computer system100 may be associated with a software provider that is releasing asoftware product 166. The computer system 100 includes one or multipleprocessing nodes 110, and as illustrated in FIG. 1, a given processingnode 110 may include a security analysis and marking engine 154. Thesecurity analysis and marking engine 154 may receive input (keystrokedata, mouse or other input device-aided selections, and so forth) andprovide output (displayed images depicting charts, lists, graphs, and soforth) through a graphical user interface (GUI) 140. As an example, theGUI 140 may contain graphical controls that allow a user to select asoftware product, initiate an enumeration scan of the software product,initiate a software component vulnerability scan for third partycomponents found in the software component vulnerability scan, access amaster database blockchain, access SCVE blockchains, generate SCVEblocks, and so forth, as described herein. It is noted that although theGUI 140 and security analysis and marking engine 154 are depicted inFIG. 1 as being single components, in accordance with exampleimplementations, the security analysis and marking engine 154 may beformed from separate components, which may have associated GUIs.

In accordance with example implementations, the security analysis andmarking engine 154 is constructed to perform an enumeration scan of thesoftware product 166 for purposes of determining an inventory of allinformation that is present in the software product 166, includingthird-party components. For these third-party components, the securityanalysis and marking engine 154 is further constructed to scan asoftware component vulnerability database 190 for purposes ofidentifying any vulnerabilities associated with these third-partycomponents. As an example, this scan may, for example, retrieving datarepresenting all of the entries of the software component vulnerabilitydatabase 190; searching the data for software component keywords; andidentifying entries that corresponds to the third-party components thatwere identified in the enumeration scan. Based on the results of thedatabase scan, remediation measures may be undertaken by the softwareprovider for purposes of addressing any previously unaddressedvulnerability risks that are found via the database scan.

As described further herein, an authority associated with the softwarecomponent vulnerability database 190 publishes a master databaseblockchain 156, which is a cryptographic ledger representing all changesthat are made to the database 190. In accordance with exampleimplementations, for a particular release, or version, of the softwareproduct 166, the security analysis and marking engine 154 creates avalidation stamp 166 for the product release. In accordance with exampleimplementations, the validation stamp 166 contains a reference 167 to ablock number, or page, of an application blockchain 157, whichcorresponds to the product release; and the validation stamp 166contains a reference 169 to a block number, page, of the master databaseblockchain 156, which corresponds to the product release. Theapplication blockchain 157 may be published by the software provider,and the master database blockchain 156 may be published by the authorityfor the software component vulnerability database 190. The applicationblockchain reference 167 allows consumers of the software product 166 toknow the third-party component inventory of the software product 166.The master database blockchain reference 169 allows the softwareprovider to prove the state of the software component vulnerabilitydatabase 190 when scanned by the provider; and the master databaseblockchain reference 169 allows consumers of the software product 166 todetermine which third component vulnerabilities have been addressed inthe release.

In accordance with example implementations, the processing node 110 mayinclude one or multiple physical hardware processors 150, such as one ormultiple central processing units (CPUs), one or multiple CPU cores, andso forth. Moreover, the processing node 110 may include a local memory160. In general, the local memory 160 is a non-transitory memory thatmay be formed from, as examples, semiconductor storage devices, phasechange storage devices, magnetic storage devices, memristor-baseddevices, a combination of storage devices associated with multiplestorage technologies, and so forth.

Regardless of its particular form, the memory 160 may store various data164 (data representing software component identifiers, third partycomponent identifiers, vulnerability entries (descriptions, IDs, publicsource links, and so forth), master database blockchain data, softwarecomponent vulnerability entry block chain data, product identificationinformation, hashes, blockchain block numbers, and so forth). The memory160 may store machine executable instructions 162 (i.e., software) that,when executed by the processor(s) 150, cause the processor(s) 150 toform one or multiple components of the processing node 110, such as, forexample, the security analysis and marking engine 154, the GUI 140, andso forth.

In accordance with some implementations, each processing node 110 mayinclude one or multiple personal computers, workstations, servers,rack-mounted computers, special purpose computers, and so forth.Depending on the particular implementations, the processing nodes 110may be located at the same geographical location or may be located atmultiple geographical locations. Moreover, in accordance with someimplementations, multiple processing nodes 110 may be rack-mountedcomputers, such that sets of the processing nodes 110 may be installedin the same rack. In accordance with further example implementations,the processing nodes 110 may be associated with one or multiple virtualmachines that are hosted by one or multiple physical machines.

In accordance with some implementations, the processor 150 may be ahardware circuit that does not execute machine executable instructions.For example, in accordance with some implementations, the securityanalysis and marking engine 154 may be formed in whole or in part by anapplication specific integrated circuit (ASIC), a field programmablegate array (FPGA), and so forth. Thus, many implementations arecontemplated, which are within the scope of the appended claims.

As also depicted in FIG. 1, the processing node 110 may communicate withthe software component vulnerability database 190 over network fabric170. Moreover, the processing node 110 may communicate over the networkfabric 170 to receive data representing the master database blockchain.In general, the network fabric 170 may include components and useprotocols that are associated with any type of communication networkand/or multiple types of communication networks, such as (as examples)Fibre Channel networks, iSCSI networks, ATA over Ethernet (AoE)networks, HyperSCSI networks, local area networks (LANs), wide areanetworks (WANs), wireless networks, global networks (e.g., theInternet), or any combination thereof.

FIG. 2 depicts the master blockchain 156, in accordance with exampleimplementations. For this example, the master database blockchain 156includes P blocks 204, including a genesis block 204-1 (representing aninitial state of the software component vulnerability database 190) andadditional blocks 204 that have been added (in direction 201) torepresent changes to the database 190. A block 204 of the masterdatabase blockchain 156 represents a particular state of the softwarecomponent vulnerability database 190 at a particular time that isassociated with the block 204. A particular block 204 may represent aset of one or multiple changes to the software component vulnerabilitydatabase 190 (relative to the immediate previous block 204), and aparticular block 204 may represent the copying of the database 190 at aparticular time. For the state of the master blockchain 156 depicted inFIG. 2, block 204-P represents the current state of the softwarecomponent vulnerability database 190.

In accordance with example implementations, each block 204 of the masterdatabase blockchain 156 contains multiple SCVE blockchains 210: one SCVEblockchain 210 for each entry of the software component vulnerabilitydatabase 190 (FIG. 1) existing at the time associated with the block204. For the illustration of FIG. 2, the genesis block 210-1 has N SCVEblockchains 201 corresponding to the N entries of the software componentvulnerability database 190. The number of SCVE blockchains 210 may varyamong the blocks 204, as the number of entries of the software componentvulnerability database 190 may vary, as new entries may be added anddeleted over time.

The SCVE blockchain 210 is a cryptographic ledger that representstransactions that have been made to a corresponding entry of thesoftware component vulnerability database 190. In accordance with someimplementations, each block of an SCVE blockchain 210 may represent atransaction that is made by a security reporter to the entry, and thetransaction is associated with a particular time.

Referring to FIG. 2 in conjunction with FIG. 1, an SCVE blockchain 210may be created due to the addition of an entry to the software componentvulnerability database 190 by a security reporter, and new blocks may beadded to an existing SCVE blockchain 210 by security reporters toreflect changes to a corresponding existing entry of the database 190.FIG. 1 illustrates a security reporting engine 130, which may be used(via the GUI 140 or another GUI) by a security reporter to extend aparticular SCVE blockchain 210 when an entry (an actual entry or areserved entry) of the software component vulnerability database 190 isto be modified or created. It is noted that although FIG. 1 depicts thesecurity reporting engine 130 as being part of the processing node110-1, the security reporting engine 130 may be located on anotherprocessing node 110. Moreover, the security reporting engine 130 may beused by a security reporter other than a security report that isaffiliated with a software provider or affiliated with a securityanalysis and marking engine 154, in accordance with further exampleimplementations.

To change or add an entry to the software component vulnerabilitydatabase 190, a security reporter may use the security reporting engine130 to create a transaction that adds or changes an entry to thedatabase 190. Through the security reporting engine 190, the securityreporter may retrieve the current published master blockchain 156,retrieve the corresponding SCVE blockchain 210 (that corresponds to theentry being modified or created) and create an additional block for theSCVE blockchain 210 to extend the blockchain based on the createdtransaction.

In accordance with example implementations, the security reporter has aprivate key (part of a private key and public key pairing), which thesecurity reporter may use (via the security reporting engine 130) todigitally sign the new block and communicate the signed block to themanagement authority for the software component vulnerability database190. Using the public key of the pair, the management authority may thenvalidate the new block and correspondingly make the decision whether thenew SCVE block is valid. The management authority may receive other suchnew SCVE blocks, such that, at a certain interval, the managementauthority may update the software component vulnerability database 190with a set of entry changes and correspondingly publish a new block 204of the master database blockchain 156. As depicted at reference number214, in FIG. 2, the database authority may add information to the block204. In particular, the blocks 204 may be digitally signed by themanagement authority using a private key (part of a private key andpublic key pair), as depicted at reference numeral 213. The public keyof the pair may be used to validate the blocks 204. Referring also toFIG. 4, the information 214 that is added by the management authoritymay further include a timestamp 402 and the public key 404 of themanagement authority.

FIG. 3 illustrates the SCVE blockchain 210 in accordance with exampleimplementations. As noted above, the SCVE blockchain 210 is a ledgerrepresenting changes to a particular entry of the software componentvulnerability database 190 over time. Each set of changes is representedby a block 304, with block 304-1 being the genesis block (representingthe entry as created), and block 304-Q for this example being the latestblock 304. For the example that is depicted in FIG. 3, the SCVEblockchain 210 corresponds to the entry ID of “CVE-2018-0009,” and thegenesis block 304-1 contains a record 306 that describing the entry asoriginally created. A timestamp 308 of the block 304-1 contains datarepresenting the time that the block 304-1 was created, and the block304-1 contains a public key 314 of the security reporter who digitallysigned the block 304-1 (as represented at 315) with a private key(paired with the public key 314).

FIG. 3 further depicts a block 304-2 describing a change to theCVE-2018-0009 entry. The block 304-2 contains a record 320 describing achange to the entry, along with a timestamp 322, a public key 324 of thesecurity reporter making the change and a digital signature 325 by thesecurity reporter.

As mentioned above, the master blockchain 156 may be extended based onchanges to the database as well as copies being made of the database. Inthis manner, FIG. 4 depicts a master block 204 containing a timestamp402, a public key 404 of the management authority for the database and acorresponding signature 408 of the authority representing extension ofthe master block 156. In a similar manner, the authority for thedatabase may extend the master blockchain each time another transactionis created detailing a particular set of one or multiple changes to thedatabase.

In accordance with some implementations, the management authority forthe software component vulnerability database 190 may be a single,central entity, such as the MITRE Corporation. However, in accordancewith further example implementations, the authority for the database maybe a distributed authority that is formed from multiple entities. Forexample, in accordance with some implementations, authorized securityreporters may have dual roles for verifying extensions to SCVEblockchains and corresponding extensions to the master blockchain. Inaccordance with some implementations, a consensus of database managementauthority entities may be required before a SCVE and/or masterblockchain extension is allowed.

Referring to FIG. 5 in conjunction with FIG. 1, in accordance withexample implementations, the security analysis and the marking engine154 may perform a technique 500 that includes performing (block 504)product component enumeration and scanning (block 508) a componentvulnerability database for entries in the database corresponding tocomponents that are identified in the product component enumeration. Thetechnique 500 includes the engine 154 identifying (block 512) a masterblockchain block number engine rating (block 516) a validation stamp forthe software product release. As an example, the validation stamp mayinclude one or multiple product identifiers (a product name, a productlocation, a description of the product, a hash of the contents of theproduct, and so forth) and a component vulnerability state (a masterblockchain block number, identifiers for components in the masterblockchain and identifiers for the software product, as examples).

In accordance with some implementations, a technique 600 may be used forpurposes of extending the master blockchain. Pursuant to the technique600, the current master blockchain may be accessed, pursuant to block604 and SCVE blockchain that corresponds to an entry being created,changed or reserved may be accessed, pursuant to block 608. A record maythen be generated (block 612) describing the creation, change orreservation of the entry and a corresponding timestamp may be generated,pursuant to block 612. A block may then be generated (block 620) toextend the SCVE blockchain including a record describing thetransaction, the timestamp, the public key of the security reporter andthe digital signature of the security reporter. The block may then besent (block 624) to a database authority for verification and inclusionin the SCVE blockchain and master blockchain.

Thus, referring to FIG. 7, in accordance with example implementations, atechnique 700 includes determining (block 704), by a computer, entriesof a software vulnerability database associated with a plurality ofcomponents associated with a release of a software product. Thetechnique includes determining (block 708), by the computer, a block ofa blockchain representing a vulnerability state of the plurality ofcomponents and associating (block 712), by the computer, the block ofthe blockchain with the product release.

Referring to FIG. 8, in accordance with example implementations, anon-transitory machine readable storage medium 800 stores instructions818 that, when executed by a machine, cause the machine to determineentries of a software vulnerability database associated with a pluralityof components associated with a release of a software product anddetermine a block of a blockchain representing a vulnerability state ofthe plurality of components. The instructions 818, when executed by themachine, further cause the machine to associate the block of theblockchain with the product release.

Referring to FIG. 9, in accordance with example implementations, anapparatus 900 includes at least one processor 920 and a memory 910. Thememory 910 stores instructions 914 that, when executed by theprocessor(s) 920, cause the processor(s) 920 to determine an enumerationof components associated with a software product; based on theenumeration, identify vulnerabilities published in a database associatedwith the components; generate a block of a blockchain representing astate of the database; and generate a stamp to be associated with arelease of the software product. The stamp represents an index to theblock of the blockchain.

While the present disclosure has been described with respect to alimited number of implementations, those skilled in the art, having thebenefit of this disclosure, will appreciate numerous modifications andvariations therefrom. It is intended that the appended claims cover allsuch modifications and variations.

What is claimed is:
 1. A method comprising: determining, by a processorof a computer, an inventory of components that are contained in aparticular version of a software product; identifying, by the processor,vulnerable components of the particular version of the software productthat have vulnerability risks, by identifying entries of a softwarevulnerability database that correspond to any components in theinventory of components; generating, by the processor, a block of adatabase blockchain representing a state of the software vulnerabilitydatabase at a time when the vulnerable components were identified,wherein each block of the database blockchain represents a differentstate of the software vulnerability database; and generating, by theprocessor, a validation stamp containing a first reference to anapplication block that contains the inventory of components of theparticular version of the software product and a second reference to theblock of the database blockchain that represents the state of thesoftware vulnerability database at the time the vulnerable componentswere identified.
 2. The method of claim 1, wherein the application blockis one block of an application blockchain, each block of the applicationblockchain representing a different version of the software product. 3.The method of claim 1, wherein the second reference comprises ablockchain page number.
 4. The method of claim 1, wherein the validationstamp further comprises data representing a hash of the softwareproduct.
 5. The method of claim 1, wherein the validation stamp furthercomprises data representing a name of the software product.
 6. Themethod of claim 1, wherein the validation stamp further comprises datarepresenting identifiers for the inventory of components.
 7. The methodof claim 1, wherein the validation stamp further comprises datarepresenting identifiers for the vulnerable components appearing in theblock of the database blockchain.
 8. The method of claim 1, wherein thedatabase blockchain comprises a master database blockchain, and themaster database blockchain comprises a plurality of componentvulnerability entry blocks representing corresponding states of theentries of the software vulnerability database.
 9. The method of claim8, wherein a given component vulnerability entry blockchain representsan entry of the software vulnerability database and changes to theentry.
 10. The method of claim 8, wherein the plurality of componentvulnerability entry blocks are associated with a plurality of securityreporters.
 11. The method of claim 8, wherein the master databaseblockchain is signed by a central authority.
 12. The method of claim 11,wherein the central authority comprises a single entity or a pluralityof entities.
 13. An apparatus comprising: at least one processor; and amemory to store instructions that, when executed by the at least oneprocessor, cause the at least one processor to: determine an inventoryof components that are contained in a particular version of a softwareproduct; identify vulnerable components of the particular version of thesoftware product that have vulnerability risks, by identifying entriesof a vulnerability database that correspond to any components in theinventory of components; generate a block of a database blockchainrepresenting a state of the vulnerability database at a time when thevulnerable components were identified, wherein each block of thedatabase blockchain represents a different state of the vulnerabilitydatabase; and generate a validation stamp for the particular version ofthe software product, wherein the validation stamp contains a firstreference to the block of the database blockchain that represents thestate of the vulnerability database at the time when the vulnerablecomponents were identified and a second reference to an applicationblock that contains the inventory of components of the particularversion of the software product.
 14. The apparatus of claim 13, whereinthe vulnerable components comprise third party components of thesoftware product.
 15. The apparatus of claim 13, wherein the databaseblockchain comprises a master blockchain, and the master blockchaincomprises a plurality of component vulnerability entry blockchainsrepresenting corresponding states of the entries of the vulnerabilitydatabase.
 16. A non-transitory machine readable storage medium storinginstructions that, when executed by a machine, cause the machine to:determine an inventory of components that are contained in a particularversion of a software product; identify vulnerable components of theparticular version of the software product that have vulnerabilityrisks, by identifying entries of a software vulnerability database thatcorrespond to any components in the inventory of components; generate ablock of a database blockchain representing a state of the softwarevulnerability database at a time when the vulnerable components wereidentified, wherein each block of the database blockchain represents adifferent state of the software vulnerability database; and generate avalidation stamp containing a first reference to an application blockthat contains the inventory of components of the particular version ofthe software product and a second reference to the block of the databaseblockchain that represents the state of the software vulnerabilitydatabase at the time the vulnerable components were identified.
 17. Thenon-transitory machine readable storage medium of claim 16, wherein theapplication block is one block of an application blockchain, each blockof the application blockchain representing a different version of thesoftware product.
 18. The non-transitory machine readable storage mediumof claim 16, wherein the second reference comprises a page number of theblock of the database blockchain.
 19. The non-transitory machinereadable storage medium of claim 16, wherein the database blockchaincomprises a master blockchain, and the master blockchain comprises aplurality of component vulnerability entry blockchains representingcorresponding states of the entries of the software vulnerabilitydatabase.
 20. The non-transitory machine readable storage medium ofclaim 19, wherein a given component vulnerability entry blockchaincomprises a plurality of component vulnerability entry blocksrepresenting an entry of the software vulnerability database and changesto the entry.